Subject: Header Formats

From: [email-masked] (Paul Brittain)
Date: Sat, 11 Jun 94 13:59:08 BST

Lakshman,

Thankyou for your feedback on the header format issues.  I have appended a copy
of your note below with clarifications to the points you queried.

Paul Brittain
Data Connection

-------------------------------------------------------------------------------
>From: Lakshman Garikapaty <[email-masked]>
>
>Paul,
>
>>We have observed from Sniffer traces of traffic between two 6611s running MPNP
>>1.2 and subsequent interoperability testing that they currently _REQUIRE_ the
>>x1D message to use a 16-byte INFOFRAME format header, and the x_BUSY plus
>>TEST_CIRCUIT messages to use 72 byte headers.  Since this is not obvious from
>>either the RFC or previous discussion on this RIGlet, it needs to be documented
>>as part of trying to provide the data necessary for backwards-compatibility.
>
>>I don't think the need for such documentation should be contentious, hence can
>>we separate it from the discussion of whether the header formats remain the
>>same or need to be changed?
>
>  Did't mean to side track your point but i have no idea what x1D msg. is?
>and when should we expect or send this message. I am also confused that
>for interoperablity testing they (who?) require to implement this msg.
>This is new to me. I guess more information is needed here.
>

The x1D appears to be a 'Wide Area Hello' message used by the 6611 to speed the
detection of lost TCP connections - but that is only a guess.  Earlier
discussions on the SIG (as it was then) determined that this message should be
quietly ignored by the receiver but did not state that it uses the short
INFOFRAME header format.

With the change of 'they' to '6611s' and 'interoperability testing' to
'testing against a 6611' (i.e. my own testing), plus a bit more punctuation,
the first sentence should become clearer thus:

 'We have observed from Sniffer traces of traffic between two 6611s running MPNP
  1.2, and subsequent testing against a 6611, that 6611s currently _REQUIRE_ the
  x1D message to use a 16-byte INFOFRAME format header, and the x_BUSY plus
  TEST_CIRCUIT messages to use 72 byte headers.'

>
>
>   There is no contention with respect to documentation but i think we
>should not clutter the data flow with backward compatiblity line items.
>We need a new section or appendix which details 6611 interoperablity. In
>this section we need all the messages that 6611 is sending that are not
>listed and which states effect etc. should be documented. Makes sense?
>
>Lakshman.

An appendix is one possible approach, or we could use a table of message
against each header type.  Either way we need to be careful not to
get distracted into spending too much time on the backwards-compatibility
section rather than working on the new standard.

As long as the fundamentals of the message formats are documented correctly, I
don't see that it is worth putting the effort into generating data flows to
contrast with any that we generate for the standard.  There may be exceptions,
for example how CAP-EX is used to detect the partner type, but this seems like
a good general rule.

---

From: Ravi Periasamy <[email-masked]>
Date: Mon, 13 Jun 94 10:31:17 EDT

Paul, Lakshman,

I would like to add some comments to the x1D message issue! 
The x1D message is sent by a 6611 to another 6611 when there is no traffic
for a while. This message is currently ignored by the other side 6611. 
The idea is that if the line is faulty this message will force the TCP 
to learn about that fact even if keep alives are not turned on.

This message sequence could be later used instead of keep alives, by
requiring a response from the target 6611.

Why was the small SSP header used? This is my guess! The long SSP headers
are used when control messages are exchanged between stations without a
connection. The header contains enough information to send the frame on the
LAN on the remote side. In some cases like XID's the long message is used
since, at one time there was a possibility that the XIDs may get sent even
when the router did not know the link station ID of the target 6611.

But x1D or a "Hallo 6611" is a message that is sent between two 6611s with
no end station or link station involved. So a larger frame type is not
needed.

This issue could be solved with a header size in the small header.
Adding to Lakshman's and Paul's suggestions to solve this problem, we
could reserve some message ids for use for vendors who may want to add
features on top of the standard, and require that all those messages 
use only the small or large headers (whatever is chosen in the standard!) 
so the target router can discard the message without going out of sync,
at the same time giving vendors the choice to be compatible with another
vendor's extensions (assuming these extensions will be open).

This will help us avoid such problems in the future when it may not be
easy to list all message types used by all vendors. Since DLSw is an
evolving protocol, it may be necessary to be flexible in the messages
that are exchanged between DLSw routers and not limit them to the list
currently being discussed.

Thanks.

Ravi Periasamy,
Cisco Systems Inc.,
[email-masked]